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i^^^HHHVAv ct Bill a business model, 
of protocols, and software implementation for commerce in infor- 
mation goods and other nerwork -delivered sendees. It has very 
low transaction costs for micropayments (around I cent for a 
10 cent item), protects the privacy of the transaction, and is 
highly scalable. Of special interest is our new certified delivery 
mechanism which delivers information goods if and only if the 
consumer has paid for (hem. This article discusses the design 
of the NetBill protocol and our World Wide Web (WWW) 
prototype implementation. 

As the explosive growth of the Internet continues, more 
people rely on networks for timely information. However, since 
most information on the Internet today is free, intellectual 
property owners have little incentive to make valuable infor- 
mation accessible through the network. There are many poten- 
tial providers who could set) information on the Internet and many 
potential consumers for that information. What is missing is an 
electronic commerce mechanism that links the merchants and 
the consumers. 

NetBill is a business model, set of protocols, and software 
implementation allowing consumers to pay owners and retailers of 
information. While NetBill will enable a market economy in infor- 
mation, we still expect that there will be an active exchange of 
free information. 

The Market for Information 

Porat and others have shown that information industries 
dominate the economy [I]. Estimates of the market for 
on-line information vary from US$10 billion to US$100 
billion per year depending upon how the market is defined [2]. 
There are more than 15.000 commercial databases accessible 
over networks. Vendors can distribute information products 
varying from complex software valued at thousands of dollars 
per copy, to journal pages or stock quotes valued at a few pen- 
nies each. A challenge for network-based electronic commerce 
is to keep transaction costs to a small fraction of the cost of the 
item. The desire to support micropayments worth only a few 
pennies each is a driving factor in the NetBill design. 

A second challenge in the information marketplace is 
supporting micromerchants, who may be individuals who sell 
relatively small volumes of information. Merchants need a 
simple way of doing business with consumers over networks, so 
that the costs of setting up accounting and billing procedures are 
minimal. A model for micromerchants is the French Minitel 



system, which provides 20.000 kiosks offering computer-based ser- 
vices to Minitel users. Many of these kiosks are provided by 
small entrepreneurs *ho enter the marketplace for little more :run 
the cost of a PC and the labor to acquire or develop valuable 
information. 

The purchase of goods over a network requires linking two 
transfers: the transfer of the goods from the merchant to the 
consumer, and the transfer of money from the consumer to the 
merchant. In the case of physical goods, a consumer can order 
the goods and transfer money over the network, but the goods 
cannot be delivered over the network. Information goods have the 
special characteristic that both the delivery of the goods and 
the transfer of money can be accomplished on the same net- 
work. This allows for optimizations in the design of an elec- 
tronic commerce system. 

A NetBill Scenario 

Figure 1 shows NetBilPs model. A consumer, represented 
by a client computer, wishes to buy information from a 
merchant's server. A NetBill server maintains accounts 
for both consumers and merchants. These accounts are linked 
to conventional financial institutions. A NetBill transaction 
transfers the information goods from merchant to consumer, 
and debits the consumer s account and credits the merchant s 
account for the value.of the goods. When necessary, funds in a con- 
sumer's NetBill account can be replenished from a bank or 
credit card; similarly funds in a merchant's NetBill account are 
made available by depositing them in the merchant's bank account. 

The transfer of an information good consists of delivering 
bits to the consumer. This bit sequence may have any internal 
structure, for example, the results of a database search, a page 
of text, or a software program. Consumers may be charged on 
a per item basis, or by a subscription allowing unlimited access, 
or by a number of other pricing models. 

Once the consumer receives the bits, there are no technical 
means to absolutely control what the consumer does with 
them. For example, suppose an information provider wants to 
charge a different price for pages viewed on-line, versus print- 
ed pages. The merchant can provide consumers with client 
software distinguishing viewing from printing, and which initi- 
ates a new billing transaction when the screen is printed. However, 
there are no technical means to prevent the consumer from 
tampering with that software once it is on her machine; a cor- 
rupt consumer who has only paid to view the bits could thus 
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bypass the charge fur printing. Merchants may 
still choose to distribute special software in the belief 
that tampering will be infrequent. Similarly, there 
is no technical means to prevent consumers from 
violating copyright by redistributing information. 1 



NetBill Design 



rhere arc a number of challenges to making 
electronic commerce systems feasible: 
High Transaction Volumes at Low Cost — 
II information is sold for a few pennies a page, 
then an electronic commerce system must handle 
very large transaction volumes at a marginal cost 
of a penny or less per transaction. 

Authentication. Privacy, and Security — The 
Internet today provide?* no universally accepted 
means for authenticating users, protecting priva- 
cy, or providing security. 

Account Management and Administration — 
Consumers and merchants must be able to establish 
jnd monitor rhcir jeeuuntv 

This article describe* the architecture ot NetBill. 
j »\wem destine J tu rreei rhesc -iO-ilv Our >tu- 
dents and we have implemented three generations 
of Net Bill prototvpe* In partnership with Visa Inter- 
njdonal jnd Mellon Bank, we will mount j trial 
in early l°°6 in which various forms of informa- 
tion are sold to consumers using NetBill. 

NetBill Architecture 

\ I e t Bill uses a single protocol that supports 
l\J charging in a wide range of service interae- 
' » tions. NetBill provides transaction support 
through libraries integrated with different client- 
server pairs. These libraries use a single transaction- 
oriented protocol for communication between client 
and server and Net Bill: the normal communications 
model between client and server is unchanged. Clients 
and servers can continue to communicate using pro- 
tocols optimized for the application — for exam- 
ple, video delivery or data base queries — while 
the financial-related information is transmitted 
over protocols optimized for that purpose. This 
approach allows NetBill to work with information 
delivery mechanisms ranging from the WWW to FTP 
and MPEC-2 streams. 

The client library —which we call the Checkbook 
— and the server library — the Till — have a well 
defined API allowing easy integration with a 
range of applications. (Below we describe how 
we integrate these libraries with web clients and http 
servers.) The libraries incorporate all security 
and payment protocols, relieving the client/server 
application developer from having to worry about 
these issues. All network communications between 
the Checkbook and Till are encrypted in order to 
protect against adversaries who eavesdrop or 
inject messages. 

The NetBill Transaction 
Protocol 

Before a consumer begins a typical NetBill trans- 
action, she will usually contact a server to locate 
information or a service of interest. For 
example, the consumer may request a Table of Con- 
tents of a journal showing available a nicies, and a 
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I Figure I . Set Bill scenario. 




I Figure 2. Transaction protocol 



list price associated with each article. NetBill pro- 
vides support for three phases in the purchase 
process: price negotiation, goods delivery, and 
payment. The process begins when the consumer 
requests a formal price quote for a product. This 
price may be different than the standard list price 
because, for example, the consumer may be part 
of a site license group, and thus be entitled to a 
marginal price of zero.- Alternatively, the consumer 
may be entitled to some form of volume dis- 
count, or perhaps there is a surcharge during the 
peak hour. 

Requesting the price quote is easy. As we dis- 
cuss below, in a WWW browser application we 
have built, a consumer requests a price quote by sim- 
ply clicking on a displayed article reference. 

The consumer's client application then indicates 
to the Checkbook library that it would like a 
price quote from a particular merchant for a 
specified product. The Checkbook library sends 
an authenticated request for a quote to the Till 
library, which forwards it to the merchant's appli- 
cation (Fig. 2. Step I). 

The merchant then must invoke an algorithm 
redetermine a price for the authenticated consumer. 
He returns the price quote through the Till, to 
the Checkbook (Step 2). and on to the consumer s 
application. 

If a merchant must perform a database lookup 
on every purchase request to determine if the 
consumer is a subscriber, the price quotation step 
becomes expensive to implement. Accordingly, 
wc have developed the notion of a credentials 
icnt- r that can issue a temporary credential to the 
consumer indicating that she is a subscriber. This 
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u>ht winch would allow 
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-' In the special case of 
frvt information, we can 
optimize our protocol mil 
funlter. 
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credential, similar in concept to a Kerberos 5 
proxy (3). can be presented with each price quote 
request to enable rapid identification of subscribers. 
Operation of credential servers can be separated 
from i he merchant service. For example, a digital 
library running at the University of California at 
Berkeley could provide site licensed material to 
all nine L'C campuses based on credentials issued 
by separate servers maintained at each campus. 

Upon receipt of the price quote, the consumer's 
application then must make a purchase decision. The 
application can present the price quote to the 
consumer or it can approve the purchase without 
prompting the consumer. For example, theconsumer 
may specify that her client software accept any 
pr»cc quote below some threshold amount; this 
relieves her of the burden of assenting to every 
low value price quote via a dialog box. 

Assume the consumer's application accepts 
the price quote. The Checkbook then sends (Step 
3 ) a purchase request to the merchant's Till. The Till 
then requests the information goods from the 
merchant's application and sends them to the 
consumer > Checkbook encrypted in aone-ttme key 

f/ir* NetBill sener is highly reliable and 



highly available. All transactions at the NetBill server are 
atomic: they either finish completely or not at all NetBill is 
never in doubt about the status of a purchase. 

(Step 4). and computes a cryptographic checksum 
(such as MD5 (4|) on the encrypted message. As 
the Checkbook receives the bits, it writes them to 
stable storage. When the transfer is complete, the 
Checkbook computes its own cryptographic 
checksum on the encrypted goods and returns to the 
Till a digitally signed message specifying the 
product identifier, the accepted price, the crypto- 
graphic checksum, and a time-out stamp: we refer 
to this information as the electronic payment order 
(EPO) (Step 5). Note that, at this point, the con- 
sumer can not decrypt the goods; neither has the 
consumer been charged. 

Upon receipt of the EPO. the Till checks its check- 
sum against the one computed by the Checkbook. 
If they do. not match, then the goods can either 
be retransmitted, or the transaction aborted at 
this point. This step provides very high assurance 
that the encrypted goods were received without error. 

If the checksums match, and the merchant agrees 
with the item description and price in the EPO. 
the merchant's application appends the decryp- 
tion key for the goods to the EPO and endorses 
— digitally signs — the entire message. The 
application sends the endorsed EPO to the Net- 
Bill server (Step 6). 

The NetBill server verifies that the consumer 
and merchant signatures are valid, indicating con- 
sumer and merchant acceptance of the terms of the 
EPO. If the consumer has the necessary funds or 
credit in her account, the NetBill server debits the 
consumer's account and credits the merchant's 
account, logs the transaction, and saves a copy of the 
decryption key. The NetBill server then returns 
to the merchant a digitally signed receipt containing 
the decryption key. or an error code indicating why 
the transaction failed (Step 7). The merchant's 



application forwards the NetBill server's receipt 
(which includes, if appropriate, the decryption 
key) to the Checkbook (Step ). 

Protocol Failure Analysis - The above descrip- 
tion assumed that no failures occurred during the 
execution of the protocol. In reality, the protocol 
must gracefully cope with network and host failures. 
One of our goals is to tightly link two events: 
charging the consumer and delivering the goods. 
The consumer should pay exactly when she 
receives the information goods. 

The NetBill server is highly reliable and highly 
available. All transactions at the NetBill server 
are atomic: they either finish completely or not at 
all. NetBill is never in doubt about the status of a 
purchase. We cannot make similar assumptions about 
the reliability of the merchant's and consumer s 
software: they must mainuin j state consistent 
with the NetBill server. 

First, consider the protocol from the perspec- 
tive of the consumer s application. Up to Step 5. 
when tne consumer application acknowledges 
receipt of the information goods, the consumer 
application knows ihat no transaction has occurred. 
That is. the consumer does not have access to tne 
product and the merchant does not have the con- 
sumers money. Once the application sends the EPO. 
the consumer is commiiied to the transaction and 
must be prepared to accept the purchase. If the 
consumer's application does not receive a response 
from the merchant's application, then it is the respon- 
sibility of the consumer's application to deter- 
mine what happened; the consumer's application 
can poll either the merchant application or the 
NetBill server to determine the status of the pur- 
chase request. If the merchant's application did 
not successfully forward the EPO to the NetBill 
server, then the EPO will have expired and the 
NetBill server will respond to the consumer s 
application that the purchase has failed. Of course, 
the consumer still does not have the one time key. 
so while the consumer still has her money, she also 
does not have the goods. If. on the other hand, 
the transaction succeeded before communication 
failed, then the consumer's application can find 
the status of the purchase and. if appropriate, the 
decryption key from either the merchant s appli- 
cation or the NetBill server (which has registered 
the key). If both are unreachable, the consumer s 
application must continue to poll. 

Now consider the protocol from the perspec- 
tiveof the merchant's application. Before it forwards 
the EPO and invoice to the NetBill server, the 
merchant s application knows that the transaction 
has not occurred. After it forwards the EPO and 
invoice, however, the merchant's application is 
committed to the transaction and must obtain the 
result from NetBill. If the merchant's application 
does not receive a response from the NetBill 
server, the merchant s application must poll the 
NetBill server. 

The protocol is much simpler for the NetBill 
server than for the other parties. The NetBill 
server is never in a state in which it depends on a 
response from another entity to determine the 
status of a transaction. Until the NetBill server 
receives the EPO and invoice from the mer- 
chants application, it knows nothing about the 
purchase. Once it receives the EPO and invoice it 
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has all the information necessary to approve or reject 
the purchase. 

We use the term certified delivery to describe 
the mechanism of delivering encrypted information 
goods and then charging against the consumer's 
Net Bill account, with decryption key registration 
both at the merchant's application and the NetBill 
server. The NetBill transaction protocol also 
exhibits a number of other desirable features: 

• Support for flexible pricing: by including the 
steps of offer and acceptance, we provide an 
opportunity for the merchant to calculate a cus- 
tomized quote for an individual consumer. 

•Scalability: the bottleneck in the NetBill 
model is the NetBill server which supports many 
different merchants. Our transaction protocol 
minimizes the load on the NetBill server and dis- 
tributes the burden over the many consumer and 
merchant machines. Note that a single interac- 
tion with the NetBill server both verifies the 
availability of funds and records the transaction. 
It ts not possible to have less than one interaction 
with the NetBill server. 3 

•Protection of consumer accounts against 
unscrupulous merchants: in a conventional credit 
card transaction, the merchant learns the consumer's 
credit card number and can submit fraudulent 
invoices in the consumer's name. In a NetBill 
transaction, the consumer digitally signs the EPO 
using a key that is never revealed to the mer- 
chant, thus eliminating this threat. Moreover, the 
consumer has proof of the exact nature of the 
information goods received, providing evidence 
in case a dishonest merchant attempts to deliver 
faulry information goods. 4 

NetBill Account Management 

In this section, we discuss how consumers and 
merchants can manage their NetBill accounts. 

NetBill supports a many-to-many relationship 
between consumers and accounts. A project 
account at a corporation can have many users 
authorized to charge against it. Conversely, an 
individual consumer can maintain multiple per* 
sonal accounts. Every account has a single user 
who is the account owner, and the account owner can 
grant various forms of access rights on the account 
to other users. 

Consumer account administration is provided 
through WWW forms. Using a standard WWW 
browser, an authorized consumer can view and 
change a NetBill account profile, authorize funds 
transfer into that account, or view a current state- 
ment of transactions on that account. Authenti- 
cation and security are provided by treating account 
information as billable items. NetBill provides 
account information to consumers using the NetBill 
protocol. NetBill can be configured to provide 
this information for free or for a service charge, 
as desired. 

Automating account establishment for both 
consumers and merchants is important for limit- 
ing costs. (Account creation is one of the largest costs 
associated with traditional credit card and bank 
accounts.) To begin the process* a consumer retrieves, 
perhaps by anonymous ftp, a digitally signed 
Net Bill security module that will work with the 
consumer's WWW browser. Once the consumer 
checks the validity of the security module, she 
puts the module in place. She then fills out a 



WWW form, including appropriate credit card or 
bank account information to fund the account, 
and submits it for processing. The security module 
encrypts this information to protect it from being 
observed in transit. The NetBill server must veri- 
fy that this credit card or banking account num- 
ber is valid and that the consumer has the right to 
access it. There are a variety of techniques for 
this verification: for example, consumers may 
telephone an automated attendant system and 
provide a PIN associated with the credit card or bank 
account to obtain a password. 

NetBill Costs and Interaction 
with Financial Institutions 

/n a modern market economy, there are many 
forms of money, but two distinct poles typify 
the range of alternatives: tokens and notanonai 
money. Currency consists of unforgeable tokens that 
are widely accepted by both buyers and sellers as 
a store of value. In a cash transaction, the seller 



mm^mtm^mmmA^ onsumer account administration is pro- 
vided through WWW forms. Using a standard WWW browser, 
an authorized consumer can view and change a NetBill 
account profile, authorize funds transfer into that account, 
or view a current statement of transactions on that account. 



delivers goods to the consumer while the con- 
sumer delivers currency to the seller. Other projects 
are developing forms of electronic currency for 
network commerce based on unique digital bit 
strings [5). 

Demand deposit accounts at a bank are an 
example of notational money: on instruction (a 
check) by a consumer, funds move from one 
ledger to another. A complex system involving 
intermediaries such as the Federal Reserve supports 
check clearing and settlements when the accounts 
are held at different banking institutions. Settle- 
ments can involve significant delays during which 
funds are not available to either party in a trans- 
action. Notational accounts can have either a 
positive or negative balance, depending upon 
whether a bank is willing to extend credit to a 
buyer. For example, a credit card account runs a neg- 
ative balance as the issuing bank executes instruc- 
tions to transfer funds to a merchant's bank account. 

Orders to transfer notational money are increas- 
ingly sent using electronic mechanisms: FedWire, 
automated clearinghouses ( ACH). credit card autho- 
rization and settlement networks, and automated 
teller machine networks are all examples. NetBill 
also uses notational money. Because both consumers 
and merchants maintain NetBill accounts, inter- 
institutional clearing costs are not incurred for every 
transaction. NetBill accounts provide a low cost 
mechanism to aggregate small-value transactions 
before invoking a relatively high fixed cost con- 
ventional transaction mechanism. Consumers move 
money into their NetBill account in large chunks (for 
example. S50 to 5100) by charging a credit card 
or through an ACH transaction. Similarly, money 
moves from a merchant's NetBill account to the 



J tn theory, one might 
bundle several transac- 
tions together and have 
them all processed as pan 
of one interaction with 
NetBill However usage 
data collected from 
Carnegie Meltons Library 
tnformanon System indi- 
cates that in the majonty 
of cases, users contacting 
the library are looking for 
a single item, suggesting 
that bundling would not 
be appmpnate. 

4 For man details on the 
security and transaction 
protocol see. B. Cox. O. 
Tygar. and St. Sirbu. 
"NetBill Security and 
Transaction Protocol " 
Proceedings of the 1995 
Usenix Workshop on 
Electronic Commerce. 
New York. July. 1995. 
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M merchant's bank through an ACH deposit trans- 
action. 

NecBill accounts can be either pre-paid (debit 
model) or post-paid (credit model). In the pre- 
paid model, funds would be transferred to Net- 
Bill in advance to cover future purchases. If the 
consumer does not have sufficient funds to cover 
a particular transaction, that transaction would 
be declined. The amount of any prepayment is set 
by the consumer, subject to minimums and maxi- 
mums established by the NetBill operator. On 
pre-paid accounts, the system allows consumers 
to designate the balance at which she is prompted 
to transfer additional funds to NetBill. Because 
ACH transactions take several days to clear, a 
consumer prepaying her NetBill account through 
the ACH may not have immediate access to the 
funds. Funding through a credit card, while incur- 
ring larger transaction fees, allows immediate 
access to a prepayment. 

In the credit model, transactions would be 
accumulated with payment to NetBill triggered 
by either time (based on a pre-established billing 
period) or dollar amount (based on a pre-established 
limit). Because granting credit creates a risk of 
non-payment, higher transaction fees may be 
associated with credit, versus prepaid accounts. 

The design space for electronic transaction 
systems has three crucial dimensions: risk, delay, and 
cost. For immediate transactions, risks of fraud or 
non-payment can be dealt with in two ways: 

• Incorporating an insurance fee proportional to the 
transaction amount. 

• Investing in sophisticated security systems with 
(high) fixed costs independent 01 transaction size. 

Credit card systems are of the first type, typically 
charging I to3 percent of the value of the transaction. 



while Fed Wire takes the second approach. Delay 
can reduce risk by allowing verification of fund 
availability before committing a transaction, and 
by allowing batching to achieve economies of 
scale, particularly in inter bank settlements. How- 
ever, delay imposes opportunity costs when funds 
are not available until cleared. 

NetBill is optimized for very low marginal 
transaction costs (on the order of I cent) on small 
value transactions (on the order of 10 cents). 
Fixed networking costs are reduced by using the 
Internet, with its substantial economies of scale, 
as opposed to a dedicated single function net- 
work. Because both consumers and merchants main- 
lain accounts at NetBill. most transfers are 
internal to NetBill; this reduces both risk and 
processing cost. When fund transfers outside 
NetBill are necessary, they can take advantage of 
aggregation, which spreads fixed transaction costs 
over larger sums. Use of ACH transfers and prepaid 
accounts minimizes risk at the cost of some delay 
before incoming funds are available: where Net- 
Bill offers deposits through credit cards, or grants 
credit itself, the risk increases and must be passed 
on to consumers xs higher fees. 

NetBill keeps other costs of operation low by: 
automating ail account idmirustration functions, 
using techniques like certified delivery to reduce the 
incidence of complaints and consumer service 
costs; and using a modern distributed processing 
approach for the core NetBill processing system. 

An Example of NetBill mth 



imp 

the World Wide Web 

Because WWW browsers and servers are a de 
facto standard for distributing information over 
the Internet, we have created a prototype imple- 
mentation of NetBill that allows for billing of 
WWW transactions. Rather than link the NetBill 
libraries with a WWW browser and http server, 
we have enabled commerce with no modification 
to either the browser or the server. Our design intro- 
duces two entities in order to support the exchange 
of money for goods: the MoneyTooi and the Prod- 
uct Server. The MoneyTooi runs on the con- 
sumer's machine and works with a Web browser. 
It allows the consumer to authenticate, select 
accounts, approve/deny transactions, and moni- 
tor expenditures. The Product Server, which 
incorporates the Till libraries, works with the http 
server to sell information products. 

When a consumer clicks on a product in a 
product server's catalog, the server returns a spe- 
cial file with a mime type containing information 
about the server's identity, the product to be ordered. • 
and the port number of the product server. This 
mime type spawns a helper program in the same way 
that jpeg. sound, and mpeg files currently do. The 
spawned program communicates the con tents of the 
file between the browser and the MoneyTooi. 

The MoneyTooi acts as the consumer's appli- 
cation in the NetBill transaction protocol described 
above. After it receives and decrypts the goods, it 
uses the remote control function of Mosaic to 
cause the browser to display the received infor- 
mation. Besides implementing the steps in the 
protocol, the MoneyTooi provides a number of use- 
ful functions to help the consumer manage trans- 
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actions (Fig. 3). The MoneyTool: 

• Provides an authentication dialog window. 

• Provides a running total of expenditures in the cur- 
rent session and (he current balance in the 
consumer s Net Bill account. 

• Provides a listing of all EPOs processed in the 
current session. 

• Can be configured to automatically approve 
expenditures below a threshold. 

• Can be used 10 retrieve the product encryption key 
from NetBill in the event of failure of a mer- 
chant host. 

Spyglass has recently proposed a standard 
Software Developer's Interface (SDI) for inter- 
facing with browsers (6) which has also won^up- 
port from Netscape. In the future we expect to 
integrate the MoneyTool with the browser using this 
mechanism. Use of the SDI interface will allow 
purchase requests to be passed directly to the 
MoneyTool without the round trip currently required 
to send back a special mime rype. 

In the current implememation.the initial request 
for goods to the htcp server causes the server to 
run a script that wntes information aboti: the request 
to a temporary file at the server. When the Prod- 
uct Server receives a request for a price quote 
from the MoneyTool. it must access the server's 
database to determine the price quote based on 
the consumer identity. If the quotation is approved, 
the product server finds the goods using the 
information saved by the help server and com- 
pletes the NetBill transaction protocol. Once we shift 
to using the SDI interface to the browser, the 
product request information will be forwarded direct- 
ly to the product server in the price request, 
avoiding the need for a temporary file. 

Additional Issues 

jm s described above, NetBill is well suited for 
/\ supporting commerce in information goods. 
/ I However, the NetBill model can also be 
extended in a variety of ways to support other 
types of purchases. For example, NetBill could be 
used equally well for conventional bill paying. A con- 
sumer could view a bill presented as a Web page: 
instead of buying information goods, we can 
think of the consumer as buying a receipt for hav- 
ing paid the bill. 

[f the product to be bought is a one -hour movie, 
it is likely that the consumer will want to stream 
the data directly to a viewer, which conflicts with 
Net Bill's model of certified delivery. We are explor- 
ing alternative approaches, such as using the 
standard NetBill protocol to periodically buy a 
key for the next N minutes of an encrypted video 
stream. 

We are also exploring the software rental 
application. A software vendor could incorporate 
the Checkbook library in any arbitrary applica- 
tion software. Periodically, the software would 
ask the consumer to approve the purchase of a 
key for the next month's operation. (This requires 
mechanisms to prevent the software vendor from 
including a Trojan Horse designed to capture a 
renter's password.) 
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